First, about the loadable kernel module for spying on things. Someone writes > In the more recent versions of [4.4-Lite-based OSes], I believe it is > not possible to load a kernel module after it has left single user > mode. Does anyone know of a hack to SunOS which affords the same > kind of `protection' ? Of course, /dev/kmem & /dev/mem would need to > become read-only devices too... I intend to attack our SunOS kernels with an eye to doing just this. I don't know how soon I'll have anything.... And second, about TCP sequence number guessing. >> This sounds to me like a serious problem. The only real fix is to >> make sure that your sequence numbers _are_ strongly random, which >> without source is difficult at best. > What I can't understand is why everyone is freaking out over this > "new" hole when it's been around forever. Speaking personally, I was aware of the theoretical potential but I had no idea most (all?) kernels used such idiotically simple and easy to predict methods to generate initial sequence numbers. (Never read smb's paper, obviously.) I think that when I do the above hacking on our SunOS kernels, one thing I'm going to do is throw a wrapper around ip_input, so that every packet received is used to corrupt tcp_iss. Probably something like use tcp_iss as a CRC accumulator and feed the packet in...almost anything will work, as long as it ensures a rapidly and unpredictably changing value. If I had source, I'd probably corrupt tcp_iss on not only received packets but also keystrokes, inode fetches from disk, context switches...almost anything could usefully be used. Depending on the clock is too weak. (There is some risk of creating a covert channel that can be used to discover useful information, such as deducing keystrokes from initial sequence number changes. In my opinion, the risk of this is quite small, and with enough other things also corrupting the ISS, it becomes vanishingly small. Force enough "covert channels" to funnel through the single 32-bit ISS variable, and they'll conceal one another quite effectively.) >> As a weak defense, you can make sure that the server->client >> messages for your TCP services vary in length, so as to make it >> impossible to carry on a complete conversation without seeing the >> packets. > I'm a little confused by what exactly you mean here (my ignorance > shines through again. :-) but it sounds intriguing, could you please > illaborate? The point of my remark was that the spoofer can't ack your machine's output without knowing how many bytes to ack. But this matters only if it's necessary for the attacker to ack it, which is not the case for many attacks; thus, on reflection, it's an even weaker defense than I thought. It helps only for services where the connection is long-lived and/or generates a lot of output, because otherwise the connection can be created, used, and killed with the generated output still sitting un-acked in the socket's send queue. der Mouse mouse@collatz.mcrcim.mcgill.edu